1. Field of the Invention
This invention relates to audio/video control (AV/C) implementations. More particularly, this invention relates to providing a methodology for accessing and interacting with AV/C descriptors within the standards of the AV/C Digital Interface Command Set General Specification.
2. The Prior Art
The IEEE 1394 multimedia bus standard is to be the “convergence bus” bringing together the worlds of the PC and digital consumer electronics. It is readily becoming the digital interface of choice for consumer digital audio/video applications, providing a simple, low-cost and seamless plug-and-play interconnect for clusters of digital A/V devices, and it is being adopted for PCs and peripherals.
The original specification for 1394, called IEEE 1394-1998, supported data transmission speeds of 100 to 400 Mbytes/second. Most consumer electronic devices available on the market have supported either 100 or 100/200 Mbytes/second; meaning that plenty of headroom remains in the 1394 specification. However, as more devices are added to a system, and improvements in the quality of the A/V data (i.e., more pixels and more bytes per pixel) emerge, a need for greater bandwidth has been indicated.
The 1394a specification (pending approval) offers efficiency improvements, including support for very low power, arbitration, acceleration, fast reset and suspend/resume features. The AV/C Digital Interface Command Set General Specification defines a command set for consumer and professional audio/video equipment over the IEEE Std. 1394-1995. Within the standard, audio/video devices are implemented as a common unit architecture within IEEE Std. 1394-1995.
Furthermore, the AV/C Digital Interface Command Set General Specification defines a set of data structures called AV/C descriptors used to provide useful information about an AV/C device and its media content. In providing useful information about an AV/C device, AV/C descriptors are similar to 1212 CSR Configuration ROMs.
Referring now to FIG. 1, a flowchart of an interpretation of the AV/C General Specification descriptor hierarchy is depicted. The following excerpt from the AV/C Digital Interface Command Set General Specification, Rev. 3.0 (the General Specification) summarizes this architecture.
The AV/C descriptor mechanism supports the creation of various data structures, both static and dynamic, which contain useful information about AV/C units, subunits, and their associated components such as plugs. Additionally, those structures can be used to model the media contents provided by these subunits.
The structures can be combined to form a content navigation and selection mechanism, which allows controllers to discover and access all media contents in a general way, limiting the media-, and subunit-type specific knowledge required to perform such tasks.
These structures are applicable to any type of unit and subunit definitions of the AV/C protocol.
A descriptor is an address space on a target that contains attributes or other descriptive information. One example is the subunit identifier descriptor, which is a data block containing various pieces of information regarding a particular type of subunit. The format and contents of the subunit identifier descriptor are unique to each type of subunit. For example, all tuner subunits will have the same kind of subunit identifier descriptor. Most of the information in this structure is static in nature. However, depending on the type of subunit and the particular technologies that it implements, it is possible that some of the information may change from time to time.
Other standard descriptor structures include, an object list and the object entries that it contains. An object is a generic concept that applies to a particular type of subunit, which can be defined as needed. For example, a tuner subunit implements an object list, which contains information about the various services, which are available on the system. Each service is represented by an object.
Other examples of where objects may be useful might be for disc players, where the objects represent tracks on the media. For digital still cameras, objects could be the pictures that have been taken.
An object list is a generic container concept; each entry in the list is an object descriptor structure. These may also be referred to as object entries, or simply, objects.
Objects and object lists can be used to model data relationships where one entity is composed of several sub-entities. For example, an audio compact disc (CD) can be composed of the collection of audio tracks on that disc.
In the above example, an object would be used to describe the CD. That object would, in turn, have a reference to a list of objects, where each one represents an audio track. Further extending the example, a collection of several CD's can be represented by a list, where each object entry describes one of those CD's.
The hierarchical model of lists and objects can be continued to any arbitrary level of complexity.
We define the root or beginning of a hierarchy to be a list, which may contain one or more objects. This list will be accessible by its list_ID value, which can be found in the subunit identifier descriptor. A subunit identifier descriptor may refer to several root lists.
When traversing away from the root, we say that we are moving down in the hierarchy. Conversely, when moving toward the root, we are moving up in the hierarchy. There is only one root for the hierarchy, and there may be any number of leaf nodes (end points).
When an object entry has object lists associated with it, we say that the object entry is a parent. The object list that it refers to is a child.
So, object lists, which are referred to by the subunit identifier descriptor, are root lists; all other lists, which must be referred to by objects within other lists, are child lists. Object lists and object entries are defined per subunit type (tuner, etc.). There may or may not be crossover usage in other subunit types, depending on the definitions.
The unit and subunit identifier descriptors mentioned in this document are examples of descriptor structures; objects and object lists are also descriptors. When a controller wants to access a descriptor, it will use the descriptor commands to specify which descriptor it wants to deal with.
One very important fact to understand is that the structures of the various descriptors defined here are for interfacing purposes, where two separate AV/C entities (a target and a controller) must exchange information. The internal storage strategy used by a particular entity is completely transparent to these interface definitions. Data can be stored in any manner or location as required by the entity. Only when it comes time to present it to a controller will it be necessary to use these structure formats.
Thus, as may be gleaned from the above excerpt from the General Specification, in providing useful information about the media content of an AV/C device, AV/C descriptors are more similar to a networked file system. For example, AV/C descriptors are used to indicate the title of a MiniDisc in an AV/C MiniDisc player. Since MiniDiscs are writable, the disc title may be changed on the media, and AV/C descriptors are used to do so. In this case, then, AV/C descriptors may be both read and written. Thus, access to AV/C descriptors must be controlled as in a file system to prevent multiple controllers from simultaneously attempting to write to the same descriptor. Therefore, the AV/C descriptor architecture, generally, provides methods for opening access to descriptors, much like file systems do.
AV/C descriptors also provide status information such as the current amount of play time into a MiniDisc. This information is highly dynamic, changing as much as 10 times a second. Unlike other types of descriptors, status descriptors are not preconstructed in system memory and directly read when an AV/C controller reads the descriptor. Instead, the status descriptor information is read only when a descriptor read request is received. Typically, obtaining the status information involves calling a procedure which communicates with the disc mechanism controller.
The various types of descriptor information may be intermixed within the same descriptor structure. Thus, certain parts may be read only and others read/write, and some parts may be fairly static and directly accessed from memory while other parts are highly dynamic and must be obtained by calling a procedure.
Like the 1212 Configuration ROMs and file systems, AV/C descriptors are arranged in a hierarchical format. Each descriptor may have child descriptors. In a file system, each node in the hierarchy is accessed as a unit independent of its children. For example, opening access to a directory does not affect access to files within the directory. In addition, opening access to a directory allows reading of the contents of the directory but does not allow reading of the contents of the files within the directory. AV/C descriptors, however, do not provide the same treatment with regards to descriptor access. Opening access to an AV/C descriptor may also open access to many if not all of its children. In addition, opening access to an AV/C descriptor allows reading both the descriptor and often its children. Thus, access to a descriptor may be opened by opening the descriptor itself, its parent, its parent's parent, and so forth.
Because of the AV/C descriptor access methods, an AV/C descriptor may be accessed as a whole unit or as a part of a parent descriptor. When an AV/C controller reads a descriptor, it specifies the starting address within the descriptor to begin reading. This descriptor “address space” depends upon how a descriptor is accessed. If a descriptor is accessed as a whole unit, the first field in the descriptor is located at address 0. However, if the descriptor is accessed as a part of its parent, the first field is not address 0, but another address. Thus, the fields within a descriptor are located at different addresses depending upon the type of descriptor access; descriptors, therefore, may have multiple address spaces.
Attempting to implement an AV/C descriptor as a whole is thus very difficult. Doing so may involve several types of data formats, storage and retrieval methods, access methods, and address spaces. The general specification implies attempting to implement each AV/C descriptor as a whole, leading to an implementation that is difficult to manage and different for each type of descriptor and device. The General Specification, however, leaves open the actual implementation methodologies and strategies to developers as long as the methodology or strategy stays within the parameters of the specification. That is, as long as when it comes time to present data to a controller, the prescribed structure is utilized. How this is implemented is not prescribed.